1. Field of the Invention
This invention relates to servicing requests in a Service Component Architecture (“SCA”) and more particularly relates to supporting SCA service requests to service components written in non-native runtime code.
2. Description of the Related Art
SCA is a protocol which describes a model for building applications and system using a Service-Oriented Architecture (“SOA”). SCA extends and compliments previous methods of implementing services and builds on open standards. SCA promotes an SOA organization of business application code based on components that implement business logic. The components offer services through service-oriented interfaces and make use of functions and services offered by other components through service references.
An application or program running on a client computer, server, or the like may desire to use a service made available by a component through a computer network such as the Internet, a wide area network, a local area network, or the like. An integration server, such as the WEBSPHERE® Process Server (“WPS”) by International Business Machines (“IBM”) of Armonk, New York may be used as an intermediary between a computer from which a service request originates and a computer hosting the desired service or function. Integration servers use a native programming code, such as JAVA® code.
Components written in the native code of the integration server may be accessed by the integration server to process service requests. Components written in non-native code, such as C, .NET Framework, Common Business Oriented Language (“COBOL”), and the like, present a compatibility problem for the integration server. Currently, components written in non-native code may be accessed if the components are compiled into a Common Object Request Broker Architecture (“CORBA”) Object Request Broker (“ORB”) or the like and used by an Internet Inter-Orb Protocol (“IIOP”). Using CORBA ORBs limits the use of non-native components.
Furthermore, current support for non-native components is not readily extendible. In particular the runtime software for current integration servers is limited to a predefined and compiled runtime “engine” which requires service components to be written and compiled into a native type of code, or support the IIOP protocol. The predefined and compiled runtime “engine” is not readily adaptable to accept service calls to executable code written and/or compiled into non-native code formats or languages.
From the foregoing discussion, it should be apparent that a need exists for an apparatus, system, and method that support, and are readily extendable to support, service components written in non-native runtime code in a Service Component Architecture. Beneficially, such an apparatus, system, and method would provide more flexibility in allowing access to non-native components than currently available solutions.